Dans un long rapport sur la sécurité, Akamai pointe les dangers qui entourent désormais les API (Application Programming Interface). La société fournit une série de chiffres significatifs, dont une envolée de 49 % des attaques visant ces interfaces entre les premiers trimestres 2023 et 2024. Akamai encourage les entreprises à s'en prémunir et à se montrer proactives.
Akamai est un géant de l’internet. La société dispose de plus de 100 000 serveurs à travers 135 pays, mettant à disposition d’immenses caches partout sur la planète. Ces caches servent à stocker des contenus et ainsi à économiser la bande passante. De très nombreuses entreprises sont clientes d’Akamai, dont des géants de la tech (Adobe, Apple, Meta, Microsoft…) ou encore des médias (New York Times, Reuters…). En France AlloCiné, France 2, TF1 ou encore les sites de la SNCF se servent des serveurs d’Akamai.
À la manière de Cloudflare, la société est bien placée pour avoir une vue d’ensemble de ce qui transite par la tuyauterie d’internet. Et la société y a constaté, elle aussi, une augmentation significative des attaques contre les API et les applications web. Elle dit avoir enregistré la bagatelle de 108 milliards d’attaques contre les interfaces de programmation, sur une période allant de janvier 2023 à juin 2024. Une tendance sur laquelle Akamai avertissait déjà dans un rapport State of the Internet de l’année dernière.
Dans cette première partie, nous nous pencherons sur les API. Dans une seconde actualité, nous reviendrons sur les infrastructures, les attaques par déni de service distribuées et le DNS.
Des interfaces désirables
Les API deviennent progressivement l’un des principaux moyens de conduire des attaques, indique Akamai dans son rapport. Non pas que les autres vecteurs soient délaissés. L’exploitation de failles 0-day est toujours aussi appréciée des pirates. Mais encore faut-il avoir sous la main ces précieuses failles qui, par définition, ne sont connues que de peu d’acteurs et peuvent se monnayer des millions de dollars/euros.
Par contraste, les API sont plus simples d’accès. Elles sont très nombreuses, en raison de l’intensification de leur utilisation et le nombre de projets qui en exposent. D’anciennes versions sont parfois laissées pour des raisons de compatibilité, puis oubliées alors qu’elles sont pourtant bien fonctionnelles (API fantômes) ; des cibles de choix pour les pirates.
Les API sont autant d’éléments que l’on peut interroger pour déclencher une action. Leur multiplication sans fin rend délicate une protection adéquate, car elles sont rarement considérées comme des composants critiques.
« La priorité accordée à la gestion des correctifs est un conseil de base des organismes de cybersécurité, mais de nombreuses entreprises ont encore du mal à mettre en œuvre des protocoles de gestion des correctifs efficaces », indique ainsi Akamai. La situation n’est guère différente d’autres éléments logiciels. La société évoque par exemple une campagne toujours en cours contre les applications ThinkPHP. Elle exploite deux failles (CVE-2018-20062 et CVE-2019-9082) connues depuis 2018, mais toujours pas corrigées dans une partie des organisations.
Une intensification des attaques
Pour donner une idée de cette désirabilité, Akamai donne plusieurs chiffres représentatifs. D’abord, une hausse de 49 % des attaques visant les applications et les API entre janvier 2023 et juin 2024. Akamai en comptait ainsi 14 milliards par mois en moyenne au début de la période, et environ 26 millions par mois en juin dernier.
Pour les seules API, 40 milliards d’attaques ont été enregistrées durant le premier trimestre de cette année, contre 35 milliards à la même période l’année dernière (qui voyait déjà une intensification). Des attaques pas toujours simples à détecter, car il peut s’agir « seulement » d’abuser d’un processus prévu par l’équipe de développement.
Une fois compromises, les API peuvent fournir un accès à des ressources normalement inaccessibles, dont des données sensibles. C’est ce qui s’est passé pour un opérateur américain qu’Akamai ne cite pas, mais dont l’abus d’une API a permis la récolte de 37 millions d’enregistrements de clients. Le rapport ajoute que les vols de données ne sont pas les seuls éléments à craindre : érosion de la confiance des clients, atteinte à la marque et à la réputation, et problèmes potentiels de conformité sont cités.
Les attaques les plus courantes
Dans les scénarios visant les API, les attaques par inclusion de fichier local (LFI), script intersite (XSS), injection SQL (SQLi), injection de commande (CMDi) et falsification de requête côté serveur (SSRF) sont les plus courantes.
Il y a peu de variation dans les méthodes employées dans ce domaine avec le temps. Akamai fournit une explication : elles « persistent en raison de leur efficacité à exploiter les vulnérabilités courantes des applications web et des API, qui découlent souvent d'une validation inadéquate des entrées et d'une mauvaise configuration de la sécurité ».
L’inclusion de fichier local a par exemple une hausse spectaculaire de 120 % entre les premiers trimestres 2023 et 2024. Les injections SQL et de commande ont, elles, grimpé de 25 sur la même période. Les attaques LFI, XSS et SQLi sont tout particulièrement efficaces, car elles exploitent « des faiblesses fondamentales dans les pratiques de conception et de développement », assène Akamai.
Le rapport cite de nombreux facteurs pouvant aboutir à ce manque de qualité dans le code. Rapidité des cycles de développement, maintenance du code existant, ou encore insuffisance des tests de sécurité peuvent tous être liés au manque de temps. Lui-même est souvent la conséquence des contraintes imposées sur la sortie de nouveaux produits. Parallèlement, les applications web voient leur complexité augmenter. L’utilisation généralisée des API augmente mathématiquement la surface d’attaque.
Des scénarios moins courants, notamment SSRF, prennent également de l’ampleur. Ils exploitent les relations de confiance entre les systèmes internes, leur permettant de contourner une partie des contrôles de sécurité. La méthode gagne en efficacité à mesure que les organisations se tournent vers le cloud et les microservices.
Les secteurs touchés
De tous les secteurs visés, le commerce est de loin celui ayant subi le plus d’attaques contre les applications web et les API. Entre janvier 2023 et juin 2024, Akamai a ainsi enregistré le chiffre un peu fou de 164 milliards d’attaques. Selon le rapport, le commerce reste en tête pour deux raisons : une forte dépendance aux applications web et les pressions liées à la mise sur le marché. Leur combinaison ferait du secteur « une cible fiable et lucrative pour les cybercriminels ».
En deuxième place, mais loin derrière, on trouve les hautes technologies, avec 59 milliards d’attaques, toujours la même période. Les services financiers sont juste derrière, avec 55 milliards d’attaques. Sur ce secteur, Akamai note que les attaques peuvent être particulièrement problématiques, car les organisations sont dépositaires d’informations très sensibles sur les utilisateurs, ouvrant la voie à des falsifications d’identités.
Autre élément notable du graphique, l’industrie manufacturière en cinquième position. Avec 18 milliards d’attaques, l’ampleur peut surprendre, le secteur étant peu en contact avec la clientèle. Dans ce cas, c’est davantage le recours croissant aux objets connectés (IoT) qui augmente la surface d’attaque.
Une sécurisation complexe
Ici, le rapport d’Akamai rejoint largement celui de Cloudflare : face à l’intensification des attaques, la sécurité ne peut plus être envisagée seulement à travers le prisme de la correction des failles. Les entreprises doivent concevoir une approche globale de la sécurité. C’est d’autant plus vrai, souligne le rapport, « que l'abus d'API peut se produire sous différentes formes, car il provient d'utilisateurs ou d'activités qui exploitent des connexions ou des informations d'identification approuvées ».
Les organisations sont donc invitées à surveiller les API de manière permanente et à apprendre de l’évolution de leur comportement. Une fois cette étape franchie, une stratégie générale devrait être mise en place. Elle devrait inclure une compréhension profonde de la logique d’entreprise et des flux de travail, une modélisation des menaces, le catalogage complet des API (y compris les API « fantômes »), la mise en œuvre de sécurités robustes et l’utilisation de solutions de sécurité avancées.
L’inventaire des API est impératif, selon Akamai. Sur la base de ce catalogue, la société recommande d’appliquer les normes de développement les plus rigoureuses. Elle renvoie pour cela aux dix principaux risques de sécurité pour les API définis par l’OWASP (Open Web Application Security Project). Il est nécessaire également de veiller à limiter autant que possible la surface d’attaque.
« La validation de ces mesures de sécurité devrait être effectuée à l'aide d'outils d'évaluation des vulnérabilités et de tests de la posture de sécurité. Pour les systèmes opérationnels, il est conseillé de dédier une équipe à la détection et à la réponse aux menaces potentielles. Cette équipe doit être équipée pour les vecteurs d'attaque traditionnels, tels que LFI et SQLi, ainsi que pour les vulnérabilités spécifiques aux API, notamment l'authentification brisée et l'accès illimité aux flux commerciaux sensibles », ajoute le rapport.
En outre, un contrôle de l’activité des utilisateurs est « primordial » pour identifier les abus potentiels. Ces mesures devraient être accompagnées de stratégies d’atténuation rapides, ainsi que par des mécanismes de signalement.
Commentaires (12)
#1
Pour les script intersites, les protections existent également depuis longtemps, je pense aux alentours de 15 ans.
L'inclusion de fichiers locaux m'étonne aussi un peu car firefox, par exemple, refuse tout simplement de charger un script local, même sur un site totalement local.
Pour les falsification côté serveur, j'ai une vague idée car j'ai l'impression que les communications entre proxy et serveurs sont souvent en clair. Si quelqu'un a plus d'infos sur ce sujet, je suis preneur.
Ce qui est dit dans la dernière phrase est intéressant car cela permet de s'attaquer aux ennemis de l'intérieur. Quand un médecin ou un policier consulte plus de données sensibles que la moyenne, il faut qu'une alerte soit déclenchée. Tout accès à des données sensibles devrait être traçé, ce qui est probablement déjà le cas.
#1.1
Moi, pas vraiment.
Je pense que les professionnels de l'IT (j'entends par là, ceux formés réellement au développement logiciel) ne produisent pas (ou alors très très peu) ce genre de faille.
Par contre, ceux qui écrivent du code en général (les autodidactes, les reconversions, etc... et j'inclus ceux qui ont suivi un bootcamp de 4 mois pour devenir dev fullstack + admin réseau en partant de rien) ne le sont souvent pas.
Les autodidactes, si non sensibilisés, idem. Et je parle en connaissance de cause, car j'ai commencé par être autodidacte avant de me former réellement, et c'est quand j'ai commencé à me former que je me suis rendu compte de l'ampleur de ce que je ne savais pas à l'époque (génie logiciel, sécurité, etc.).
Dans le cadre de mon boulot, je côtoie des personnes qui savent pondre une API, mais dont le développement n'est pas le métier de base. Parfois elles se débrouillent très bien, des fois, c'est la cata. Quand c'est juste pour un besoin ponctuel en interne pour une tâche rébarbative, ça passe. Quand il s'agit de mettre en place un système qui va devenir une API au contact de l'extérieur, ça peut faire mal.
Le métier de développeur est aujourd'hui devenu "critique" et nécessite de nombreuses compétences, compétences que tout le monde n'a pas. Mais on manque tellement de main d'oeuvre en informatique et les salaires semblent tellement mirobolant que le développement logiciel reste, aujourd'hui encore, une voie de reconversion.
Comme je dis toujours, ce n'est pas parce que je sais aligner 2 parpaings que je sais bâtir une maison : ce n'est pas parce qu'on sait aligner 2 lignes de code que l'on est capable de faire un logiciel.
Le métier de développeur est vu par certains (et j'ai envie de dire encore trop de monde) comme un métier technique de "pisseur de code". C'est loin d'être le cas. Aujourd'hui, pour être un bon développeur, il faut savoir écrire du code, le lire, le modifier, mais aussi être alerte sur la sécurité (chiffrement & co), un minimum de connaissance sur la gestion réseau (on ne peut pas décemment développer une API web sans savoir ce qu'est un DNS ou une requête HTTP), les réglementations en vigueur (à commencer par le RGPD), et j'en passe.
#1.2
Ce n'est pas d'où te vient ta formation qui fait que tu vas appliquer l'état de l'art.
C'est ta conscience professionnelle, et l'environnement professionnel.
Si la boîte ne promeut pas de formation continue, et laisse ses devs se débrouiller, par exemple.
Historique des modifications :
Posté le 03/08/2024 à 22h28
Je suis dans une équipe r&d où les devs sont issus de formations classiques bac+5 et je peux t'assurer qu'une bonne moitié sont des pisseurs de code.
Ce n'est pas d'où te vient ta formation qui fait que tu vas appliquer l'état de l'art.
C'est ta conscience professionnelle, et l'environnement professionnel.
Le directeur r&d ne promeut aucune action de formation, les devs doivent prendre sur leur CPF et leurs congés pour se former au TDD, et autres méthodes de dev.
Posté le 03/08/2024 à 22h29
Je suis dans une équipe r&d où les devs sont issus de formations classiques bac+5 et je peux t'assurer qu'une bonne moitié sont des pisseurs de code.
Ce n'est pas d'où te vient ta formation qui fait que tu vas appliquer l'état de l'art.
C'est ta conscience professionnelle, et l'environnement professionnel.
Le directeur r&d ne promeut aucune action de formation, les devs doivent prendre sur leur CPF et leurs congés pour se former au TDD, et autres méthodes de dev.
Il veut sortir des features le plus vite possible en prod, qui a devoir casser des oeufs pour y arriver. "C'est pas grave, on corrigera après.."
Posté le 03/08/2024 à 22h30
Je suis dans une équipe r&d où les devs sont issus de formations classiques bac+5 et je peux t'assurer qu'une bonne moitié sont des pisseurs de code.
Ce n'est pas d'où te vient ta formation qui fait que tu vas appliquer l'état de l'art.
C'est ta conscience professionnelle, et l'environnement professionnel.
Le directeur r&d ne promeut aucune action de formation, les devs doivent prendre sur leur CPF et leurs congés pour se former au TDD, et autres méthodes de dev.
Il veut sortir des features le plus vite possible en prod, quitte à devoir casser des oeufs pour y arriver. "C'est pas grave, on corrigera après.."
#1.3
#1.5
Je ne sais pas si c'est école d'inge ou master info par contre.
#1.6
#1.7
Se focaliser sur la feature en cours sans prendre en compte l'environnement, les règles de CI-CD, la sécu, les tests, etc, etc
#1.8
C'est +/- le cas de la majorité des écoles d'ingé : ils poussent le commercial, la comm' et la gestion de projet en négligeant le côté technique.
Côté fac, c'est un peu pareil: certains cursus master peuvent être très spécialisés et les bases (génie logiciel, sécurité, réseau) sont appris en licence info.
En fac tu peux faire une licence de scientifique lambda puis te reconvertir en master info : en sortira un ingé informatique spécialisé sur un domaine informatique mais avec des lacunes sur certaines bases (conception / coding, sécurité, réseau...)
#1.9
Pardon si je m'énerve mais il faut revenir à mon message d'origine avant de répondre.
Je ne parle pas de chargé de projet, chef de projet ou autres, mais bien de dev et lead dev.
Des faiseurs de codes quoi.
PS: si tu fais une licence info puis un master info et qu'au final tu codes sans connaître les principes de sécurité, y'a un problème.
Historique des modifications :
Posté le 08/08/2024 à 18h02
Je parlais de dev pisseurs de code à bac+5 en info.
Pardon si je m'énerve mais il faut revenir à mon message d'origine avant de répondre.
Je ne parle pas de chargé de projet, chef de projet ou autres, mais bien de dev et lead dev.
Des faiseurs de codes quoi.
#1.10
On forme beaucoup de chef de projet (et autres spécialités), mais il y'a plutôt des postes de "pisseurs de code" surtout pour les juniors.
Du coup les RH embauchent des master info / ingé spécialisés en gestion de projet pour les mettre sur des postes de dev junior. D'où ton impression : un certain nombre de dev junior sont en fait pas spécialiste du sujet. Sans compter que les langages infos sont pas tous identiques : tu fais du prolog ou programmation formelle en fac et ton premier job c'est du Php ou du Cobol :) c'est pas du tout la même chose. Mon propos marche dans l'autre sens aussi : en sortie d' "info pisseur de code" t'es pas un cador en C++ ou Rust : ces langages sont complexes et nécessitent des années d'expérience avant d'envisager la maîtrise du langage.
#1.4
D'après ce que j'ai compris, l'article fait plus référence à des bibiolthèques non mises à jour sur des systèmes considérés comme "non critiques", même s'ils peuvent être la porte d'entrée vers d'autres systèmes. J'imagine le foisonnement d'API accumulées codées plus ou moins rapidement, puis oubliées. Je pense qu'il s'agit surtout d'une culture de la sécurité que l'entreprise a ou n'a pas. Un dev seul ne pourra pas changer tout seul une culture et sans qu'il ne soit missionné pour le faire.
Historique des modifications :
Posté le 04/08/2024 à 18h01
Les injections (SQL ou autres) sont aussi populaires que faciles à éviter (top trois dans le classement OWASP. La faille a perdu trois places depuis le même classmement depuis 2017.
D'après ce que j'ai compris, l'article fait plus référence à des bibiolthèques non mises à jour sur des systèmes considérés comme "non critiques", même s'ils peuvent être la porte d'entrée vers d'autres systèmes. J'imagine le foisonnement d'API accumulées codées plus ou moins rapidement, puis oubliées. Je pense qu'il s'agit surtout d'une culture de la sécurité que l'entreprise a ou n'a pas. Un dev seul ne pourra pas changer tout seul une culture et sans qu'il ne soit missionné pour le faire.
#2
L’avantage est qu’un BOT identifie comme malveillant, va être banni sur tout leur réseau. Cela amplifie la protection globale.
Mais tout cela a un coût…. On paye au To de traffic qui passe par la plateforme et ça peut votre grimper.
Concernant le développement, je ne peux qu’acquieser ce qui a été dit plus haut.
Souvent, certaines équipes de dev interne se sentent pousser des ailes et pondent de l’API et il ne protège rien. Du coup, il est plus important que jamais de scanner ses interfaces avec des outils automatisé pour détecter le plus tôt possible les failles avant que cela parte en production. Malheureusement comme cela prend du temps et coûte de l’argent pour ces services, c’est souvent omis, et ces interfaces partent en production telles qu’elles.
Reste plus qu’à attendre l’attaque qui plantera le serveur dans le meilleur des cas ou qui permettra une fuite de données…